Fat component, skinny pages
以下私はこれに引っ掛けて、 #フロントエンド ないし #React の世界には Fat component, skinny pages という原則が存在しうるという主張をする。 そのアプリのユーザー体験を表すような共通コンポーネントが十分になく、たとえば /pages/[id].tsx にフォームがまるごと置かれている状況はドメインコンポーネント貧血症ということができる。
こういうと、コンポーネントから責務を引きはがすこと全般に反対しているように見えるかもしれないが、そうではない。
私は React でよく言われる Container components という概念には反対していない。Fat であるとは、API や Store とつながっていることとイコールではない（そういうコンポーネントもあって良いが）。Container と Presentational の分離は Fat component の概念と両立すると言いたい。 たとえば、アイテム一覧のコンポーネントはアイテム一覧の API を叩くべきかという問題がある。
これは状況によるので一概には言えないが、叩くことでドメインコンポーネント貧血症が防がれる（のでやったほうが良い）という判断は実際にあり得ると思う。
その上で、テスタビリティを担保するためにアイテム一覧のコンポーネントが Container と Presentational に更に分離していて良い。
Skinny controller, fat model という原則は、しばしば Smart UI アンチパターンの延長、すなわち「ビューに近いところにロジックを書くな」という原則として解釈されているように見える。
しかし、私はこの理解は間違ってはないが浅い理解であると考えている。
私はこの原則は「特定のページの特定のユースケースにべったりの処理を分離せよ」というものと解釈している。
それ自体はモデルに限らず当てはまる原則であり、したがって Skinny controller で学んだ考え方は React を書く際にも応用できると思っている。「分離したいからビューに書かない」というのはたまたまそういうこともあるにすぎない。
乱暴に言うと、「ビューにロジックを書くな」というのは、つまるところ「ページのマークアップ」と「共通の UI コンポーネント」の区別が雑（したがってビューという言葉の使い方が雑）であることから出てくる発想だと思う。ちゃんと区別をしましょう。